Cell based end user interface having action cells

ABSTRACT

An EUI for presenting contents to a user, is constituted with at least a first display container cell, a second display container cell nested within the first display container cell, and an action cell nested in either the first or the second display container cell. The action cell being associated with causing at least an action to be performed in association with or on behalf with one or more display container cells.

RELATED APPLICATION

This is a non-provisional application of provisional application No.60/461,772, filed Apr. 9, 2003, entitled “Methods and Use of Icons ThatRepresent Elements of a Multi-Window EUI”. This non-provisionalapplication claims priority to said '772 provisional application, whichspecification is hereby incorporated by reference, to the extent it isconsistent with the specification and claims to follow.

For the United States of America, this non-provisional application isalso a continuation-in-part of co-pending U.S. application Ser. No.10/136,669, filed Apr. 30, 2002, entitled “A Cell Based End UserInterface”, which itself claims priority to:

-   a) No. 60/287,933, entitled “A MULTI-WINDOW EUI FOR MULTI-MEDIA    CONTENT/PROGRAMMING DELIVERY INCLUDING AUTOMATIC RELATIVE RESIZING”,-   15b) No. 60/287,972, entitled “HIERARCHICAL ELEMENTAL STRUCTURE IN    SUPPORT OF A MULTI-WINDOW EUI”,-   c) No. 60/287,663, entitled “BEHAVIOR OF NESTED COMPLEX ELEMENTS”,-   d) No. 60/287,943, entitled “STATE TRANSITION FOR A MULTI-WINDOW EUI    WITH HIERARCHICAL ELEMENTS”,-   20e) No. 60/287,980, entitled “EFFICIENT REGION IMPACT DETERMINATION    FOR MULTI-WINDOW EUI”,-   f) No. 60/287,977, entitled “REGIONS AND ZONE MODIFICATION FOR A    MULTI-WINDOW EUI”, and-   g) No. 60/287,932, entitled “EXPANDABLE CONTROL FACILITY FOR AN END    USER INTERFACE”;-   all filed on Apr. 30, 2001, and which specifications are all hereby    fully incorporated by reference, to the extent they are consistent    with the specification and claims to follow.

Accordingly, for U.S., the present application, through said '669non-provisional application, also claims priority to the '933, '972,'663, '943, '980, '977, and '932 provisional applications.

FIELD OF THE INVENTION

The present invention relates to the field of data processing. Morespecifically, the present invention relates to end user interfaces.

BACKGROUND OF THE INVENTION

With advances in integrated circuit, microprocessor, networking andcommunication technologies, an end user of a properly equippedtelevision set or a computing device may receive and consume a varietyof multi-media contents or programming via a number of differentdelivery channels. The end user may e.g. receive and consume programmingdelivered through conventional network broadcast, cable or satellite.The end user may also receive and consume various multi-media contentsor programming delivered from various recorded media players, such asVCR tape players, CDROM or DVD players. Alternatively, the end user mayalso receive and consume various streaming multi-media contents orprogramming delivered through the Internet or other high-speed digitalchannel. The end user may also want to work on multiple files, programs,applications or data on their computer.

The end user interfaces (EUI) employed in these multi-media contentapplication interfaces on a computer screen or other display device,Operating System interfaces, or programming deliveries are typicallylimited in their functionalities and ease-of-use. In particular, theyare typically fixed or inflexible, i.e. non-responsive or lackinteractivity with the user. For example, in the case of televisionprogramming, typically only a single view of a program (chosen by adirector) is provided to the end user (even though multiple views areavailable from the multitude of cameras employed to cover an event orperformance). Even at times, when multiple views of a program or windowsof an application or multiple different applications have multiplewindows open and are provided, the user is unable to change the size,and/or placements of the different display windows within which theviews are displayed. Where modifications of the size and/or placement ofthe display windows are supported (hereinafter, simply windows),typically, automatic relative re-sizing and/or placement of the windowsfrom either unrelated applications, programs or sources across a networkor even from a single source, are not supported. That is, expansion of awindow will often result in the blocking of another window (unless theexpanding window is a “transparent” window), and contraction of a windowwill often result in excess unconsumed space (unless the end user takesovert action to enlarge another window). Similar limitations exist inthe delivery of multi-media contents, typical computer displayinterfaces, GUI's of single applications, operating system presentationof multiple windows from multiple applications, sources or programmingfrom recorded media, or windows and/or content associated with streamingthrough the Internet.

Further, the different windows (whether it is of the same program or ofdifferent programs) are usually not easily interchangeable. Inparticular, associated controls, such as “minimize”, “maximize”, or taskbars, are typically not relocatable from one window associated with oneapplication to another window associated with another application. Forexample, in the case of television programming, different views of thesame program delivered through multiple windows are generally notinterchangeable, whereas different programs delivered through differentwindows, such as a primary view and a “picture-in-picture” (PIP) view,are swappable, provided the end user separately changes the channelsassociated with the two windows. In the case of windowed applications,control facilities associated with windows of an application, such as“minimize”, “maximize” or task bars, typically only alter or affect thecorresponding windows of the application, and may not be moved and beassociated with another window and/or another application or affect anyother application windows or display elements that they do not own (asin the relationship between parent and child windows).

Thus, an improved end user interface for content, individualapplications with multiple child windows, desktop display of related ornon-related applications, operating system window managers, and/orprogramming delivery, etc., is desired.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of exemplary embodiments,but not limitations, illustrated in the accompanying drawings in whichlike references denote similar elements, and in which:

FIG. 1 illustrates an end user view of an EUI implemented in accordancewith an embodiment of the present invention;

FIGS. 2-3 illustrates the anatomy of a cell based hierarchy forimplementing the EUI of FIG. 1, including the universal region cell,region cells, sub-region cells and zone cells, in accordance with oneembodiment;

FIGS. 4-5 illustrate selected aspects of the composition of a“container” cell, including a region cell and a zone cell, in accordancewith one embodiment;

FIG. 6 illustrates selected aspects of the composition of an “action”cell, in particular, an icon cell, in accordance with one embodiment;

FIG. 7 enumerates selected methods associated with the variousimplementation cells to support the practice of the present invention,in accordance with one embodiment;

FIG. 8 illustrates certain novel end user interface interactionssupported under the present invention, by virtual of the architecturaldesign of the hierarchical cell based EUI, in accordance with oneembodiment;

FIG. 9 illustrates the operational flow of the relevant aspects of animplementor of the present invention, such as an application, a cellmanager or a window manager, in support of the novel end userinteractions of FIG. 8, in accordance with one embodiment;

FIG. 10 illustrates the notion of a current view, and the generation ofa next view under the present invention, in accordance with oneembodiment;

FIGS. 11-12 illustrate the operational flow of the relevant aspects ofan implementor of the present invention, such as an application, a cellmanager or a window manager, in support of automatic relative re-sizingor re-placement of region cells or zone cells, in accordance with oneembodiment;

FIGS. 13-14 further illustrate automatic relative re-sizing orre-placement of region cells and zone cells, in accordance with oneembodiment;

FIG. 15 illustrates the operational flow of the relevant aspects of animplementor of the present invention, such as an application, a cellmanager or a window manager, in support of an optimized algorithm forefficiently modifying contiguous region or zone cells, in accordancewith one embodiment;

FIG. 16 further illustrates the optimized efficient modification ofregion or zone cells of FIG. 15, in accordance with one embodiment;

FIGS. 17 a -17 b illustrate two embodiments for practicing the presentinvention;

FIG. 18 illustrate an exemplary computing system or device suitable forpracticing the present invention; and

FIG. 19 illustrates an exemplary network environment suitable forpracticing the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Illustrative embodiments of the present invention include, but are notlimited to, a hierarchical cell based end user interface, havinghierarchically organized display cells (hereinafter, simply cells),processes for the end users to interact with the interface, havingparticular application to the delivery of multi-media programming and/orcontent, or having particular application to the organization ofmultiple windows of different applications running on a single clientcomputer desktop or on multiple display devices for a single or multipleclients, processes for automatically re-sizing and/or repositioningcells of the EUI, components and/or system endowed with some or allaspects of the EUI and the processes.

In the following description, various aspects of the present inventionwill be described. However, the present invention may be practiced withonly some or all aspects of the present invention. For purposes ofexplanation, specific numbers, materials and configurations are setforth in order to provide a thorough understanding of the presentinvention. However, the present invention may be practiced without thespecific details. In other instances, well-known features are omitted orsimplified in order not to obscure the present invention.

Parts of the description will be presented in data processing terms,such as data, variables, methods, requests, returns, and so forth,consistent with the manner commonly employed by those skilled in the artto convey the substance of their work to others skilled in the art. Aswell understood by those skilled in the art, these quantities take theform of electrical, magnetic, or optical signals capable of beingstored, transferred, combined, and otherwise manipulated throughmechanical, electrical and/or optical components of a computer system.

The term “display cell” (or “cell” for short) as used herein refers tothe logical elements or items employed to collectively implement thevarious aspects of the EUI. The logical elements/items or cells, as willbe described more fully below, are typed and include attributes definingthem, including their manifestation and behaviors. Visually, cells maybe “nested” within one another. Organizationally, cells may behierarchically related to each other.

The term “computer system” as used herein includes general purpose aswell as special purpose data processing machines, systems, and the like,that are standalone, adjunct or embedded. Examples of general purpose“computer systems” include, but are not limited to, handheld computingdevices (palm sized, tablet sized and so forth), laptop computingdevices, desktop computing devices, servers, and so forth. Examples ofspecial purpose “computer systems” include, but are not limited to,processor based wireless mobile phones, handheld digital music players,set-top boxes, game boxes/consoles, CD/DVD players, digital cameras,digital CAMCORDERs, and so forth.

Various operations will be described as multiple discrete operations inturn, in a manner that is most helpful in understanding the variousembodiments of the present invention, however, the order of descriptionshould not be construed as to imply that these operations arenecessarily order dependent. In particular, these operations need not beperformed in the order of presentation.

The phrase “in one embodiment” is used repeatedly. The phrase generallydoes not refer to the same embodiment; however, it may. The terms“comprising”, “having” and “including” are synonymous, unless thecontext dictates otherwise.

FIG. 1 illustrates an external end user view of an exemplary end userinterface 102, implemented in accordance with one embodiment of thepresent invention. As illustrated, exemplary end user interface (EUI)102, from the end user's perspective, includes multiple display windows104 a -104 k, control facilities 106 a -106 b and icons 108 a -108 j(each of which, as will be described in more detail below, may beeffectuated as “cells” of the EUI). EUI 102 may be employed tofacilitate delivery of multi-media contents or programming for an enduser, the presentation of multiple windows from local or remote (acrossa network or the Internet) applications or the display of data orprograms from local or remote applications. An example of suchcontent/programming includes, but are not limited to, presentation ofone or more performance or live events, such as sporting events, wherethe multiple windows are employed to present different views of eachperformance or event to the end user. An example of the presentation ofmultiple windows from a single application includes, but are not limitedto, an e-mail program that has a window that shows all e-mails availableto a user and separate windows for each e-mail that the user has openedand can now respond to, resend or forward to other respondents. Anexample of multiple applications with simultaneous open windows on oneor more desktops or screens (single or multi-screen implementations)includes, but is not limited to, the simultaneous running of one or morespreadsheet programs and one or more word processing programs, eachdisplaying windows on a common display or displays, where data,contents, video, or graphics is being copied and pasted between any twoor more separate programs. An example of a local program (client based)and a program that is delivering data from across a network, eachdisplaying windows on a common display or displays includes, but is notlimited to, a word processing program resident on a single computer anda browser that is delivering html content from a distant web site. Anexample of a local program (client based) and a program that isdelivering multimedia data from across a network, each displayingwindows on a common display or displays includes, but is not limited to,a word processing program resident on a single computer and avideoconferencing system that is delivering video, remote desktops orwhitescreen content from other videoconference participants across anetwork. Networks may include, but not be limited to, a local LAN(Ethernet, ATM, SAN, or other networking technology) or remote (ISND,TI, ATM, Frame, or other networking technology).

For ease of understanding, only a couple of control facilities 106 a-106 b and a handful of icons 108 a -108 j are illustrated with windows104 a -104 k. As will be readily apparent to those skilled in the art,based on the descriptions to follow, the present invention may bepracticed with more or less of these elements.

More importantly, as will be described in more detail below, EUI 102 isimplemented internally via a hierarchy of display cells (or cells forshort). The cells are typed and nested. Further, they have attributes,and certain attributes may be inherited in one direction, while othersin the other direction, i.e. from a higher level cell, from other cellsat the same level, or from a lower level cell (above, at the same level,or below) in the hierarchy. The cells are implemented as data objectswith associated methods to facilitate manipulation of their data.

Resultantly, one of the benefits is that the views or windows 104 a -104k are readily controllable by the end user. An end user may select anyone of windows 104 a -104 k, express a desired modification or change tothe size, placement, and/or other related aspects of the windows (suchas sound). In response, the implementation logic of embodiments of thepresent invention, e.g. a cell manager, or alternatively, a windowmanager or an application itself (not shown), will resize, re-positionor otherwise modify the selected windows, as well as all other impactedelements (cells) of EUI 102 accordingly and automatically.

Resizing may be expansion of a selected element or cell of EUI 102, orcontraction of a selected element or cell of EUI 102. Repositioning of acell may be within the existing immediately higher-level cell or toanother cell of EUI 102. In various embodiments, control facilities 106a -106 b are provided for the various windows 104* to facilitate a userin resizing, re-positioning or otherwise modifying the various aspectsof the windows 104*.

In one embodiment, as the selected and/or impacted windows 104* arere-sized, the content of each window 104* may be automatically scaled,preserving “full” visibility of the contents. That is, the contents ofthe various windows 104* remain in full view, scaled, but not truncatedor otherwise eclipsed. However, in alternate embodiments, one or morewindows 104* may have their contents truncated or eclipsed, completelyencapsulated in another cell or transformed into a completely differentcell.

In one embodiment, in addition to being employed for the delivery ofmulti-media content or programming, one or more of “windows” 104 a -104k may be employed to present a “pool” of icons (another cell type), eachcorresponding to an additional displayable or launch-able cell havingcontents, and/or action that may be performed on the content or theattributes of an associated cell. The former is referred to as an “imageicon”, and the cell implementing the “image icon” is an image-icon cell,whereas the latter is referred to as a “button icon”, and the cellimplementing the “button-icon” is a button-icon cell.

These and other aspects of the various embodiments of the presentinvention will be described more fully below. The asterisk at the end ofa reference number denotes a “wild card”, representing any of thetrailing suffixes of the reference numbers employed in a figure. Forexample, 104* stands for 104 a, 104 b or any one of the other 104references of FIG. 1.

FIGS. 2-3 illustrate the relevant aspects of the internal hierarchicalcell based implementation of EUI 102 to provide the desired improvedfeatures and behaviors, in accordance with one embodiment. Asillustrated, in accordance with the present invention, end userinterface 102 is cell based, and the constituting cells are nested (FIG.2), and the data objects implementing the cells are hierarchicallyorganized (FIG. 3).

As alluded to earlier, cells are typed, and have attributes definingtheir manifestation and behaviors. Visually, cells may be “nested”within each other. Organizationally, cells may be hierarchically relatedto each other. The attributes may be inherited in multiple directions,from the higher level cells, cells at the same level of the hierarchy,or from the lower level cells (organizationally speaking).

More specifically, for the embodiment, each EUI 102 is comprised of anumber of nested “container” cells and a number “action” cells. For easeof understanding, the “outer most” (from a nesting perspective) or thehighest-level (from a hierarchy perspective) “container” cell, that isthe cell corresponding to the totality of display space available,within which all other cells are nested, is referred to as the universalor root region cell 202. Nested within universal region 202 may be oneor more nested “container” cells. In particular, at the nexthighest-level, for the embodiment, for ease of operation, the“container” cells all have visual manifestations that are rectangular inshape, and share borders. These “container” cells are referred to asregions cells 204 a -204 c. In another embodiment, cells of any shapeare allowed at any level of the hierarchy.

Selected one or ones of the region “container” cells may further includeone or more nested “container” cells. For ease of understanding, thesenested “container” cells, except for ones disposed at the “inner most”nesting or “lowest” level (counting only “container” cells), arereferred to as sub-region “container” cells 205 a -205 b. The“container” cells disposed at the “inner most” nesting or “lowest” level(counting only “container” cells) are referred to as zone “container”cells 206 a -206 k. A zone “container” cell 206* dedicated to theholding of icon “action” cells (to be described more fully later), suchas zone “container” cell 206 i, is also referred to as an “icon pool”.

“Action” cells, such as those implementing control facilities 208 a -208b, and icons 210 a -210 j, whether they are representing otherdisplayable or launch-able cells or merely representing actions to beperformed, i.e. image icons or button icons, may be nested within(visually speaking) or descend from (organizationally speaking)) any ofthe “container” cells, i.e. the universal region cell 202, such ascontrol facilities cells 208 a -208 b and icon cells 210 a -210 d,region and sub-region cells 204 a -204 c and 205 a -205 b, none shown,or zone “container” cells, such as icon cells 210 e -210 j or indifferent structures or elements of the cells themselves (borders, titlebars, etc.).

As described earlier, control facilities may include facilities forfacilitating minimizing or maximizing an “action” cell, and an icon“action” cell may be an image or a button icon “action” cell. The“container” cell within which another “container” or “action” cell isnested or from which the other “container” or “action” cell isdescended, is also referred to as a “host” cell.

Hereinafter, the description will be given with the relationship betweenthe various cells simply be referred to as either being “nested” inanother cell or “descended” from another cell, depending on whichcharacterization is more meaningful in view of the context. However, thereference expressed from one perspective (visual or organizational) isan expression in both perspectives, even though expression in the otherperspective may not have been explicitly stated.

Continuing now with the description and referring in particular to FIG.3, for the embodiment, the data, such as attribute data (described morefully below), associated with each cell, 202 and 204*-210*, whether“container” or “action”, are organized and implemented as an hierarchyof data objects 302 and 304*-306*, with data object 302 corresponding touniversal region cell 202 being the root object of the hierarchy, dataobjects 304* corresponding to region cells 204* being descendant dataobjects of root object 302, data objects 305* corresponding tosub-region cells 205* being descendant data objects of the data objects304*-305* of their “host” region/sub-region cells 204*1205*, and dataobjects 306* corresponding to zones cells 206* being descendant dataobjects of the data objects 302 and 304*-305* of their hostuniversal/region/sub-region cells 202 and 204-205.

Contents to be presented in various windows 104*, such as video 308 a-308 e, graphics 310 a -310 b and texts 312 a -312 c are effectuated byassociating the data objects of these contents with data objects 306* ofthe zone “container” cells 206* corresponding to windows 104*. Dataobjects 314 a -314 h and 316 a -316 b implementing icons 210 a -210 jand control facilities 208 a -208 b are descendant data objects of thedata objects of their respective hostuniversal/regions/sub-regions/zones 202 and 204*-206*.

Resultantly, the novel architecture and data organization enablecontents provided through different display windows 104* to be easilyswappable, by swapping the association of the contents' data objectswith the “host” zone cell 206*. Similarly, the associations of “action”cells 208* and 210* with the different cells 202 and 204*-206* may alsobe easily changed, by changing the association between data objects314*-316* with data objects 302 and 304*-306* of cells 202 and204*-206*.

For ease of understanding, only one zone “container” cell 206 a andlimited number of “action” cells 208 a and 210 a -210 b are illustratedas being directly nested in universal region 202, only one region“container” cell 304 b as having sub-region-“container” cells 254*, andonly one zone “container” cell 206 i is deployed as an icon pool in FIG.2-3. However, the present invention contemplates multiple nesting ofmultiple “container” and “action” cells, e.g. more region/zone“container” cells as well as “action” cells may be nested in universalregion 202, more third level sub-region “container” cells and/or“action” cells may be nested within region “container” cells of thesecond level. Any nested cell or cells may be represented by an icon orhidden from view (invisible) at any level of the hierarchy. From thedescription thus far and the ones to follow, those skilled in the artwill be able to practice the present invention in such multi-levelmanner, should that be desired.

FIGS. 4-5 illustrate the composition of “container” cells, inparticular, a region “container” cell and a zone “container” cell, inaccordance with one embodiment. From the processing or computationperspective, the earlier described universal region cell 202, region“container” cell 204*, and sub-region “container” cells 205* are merelydifferent variants of the region “container” cell to be described.Accordingly, the composition descriptions to follow apply equally touniversal region-cell 202, region “container” cell 204*, and sub-region“container” cells 205*.

As illustrated, for the embodiment, associated with the definition ofeach region/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304*-306* are behavior attributesdefining whether a “container” cell 204*-206* is dynamic or fixed (i.e.created on an as needed basis, or always present), a number of structureattributes defining the structural elements of the “container” cell(kernel 4021502, boundary 406/506, etc. (to be described more fullybelow)), and a number of geometric attributes defining whether the“container” cell's position is movable or stationery, its relativepriority to other “container” cells 204*-206*, a center position, abase, a height and a maximum size of the region/zone “container” cells204*-206*: region “container” cell zone “container” cell region_type =[dynamic, fixed] zone_type = [dynamic, fixed] region_position =[stationary, zone_position = [stationary, movable] movable]region_priority = [1, 2, 3 . . . ] zone_priority = [1, 2, 3 . . . ]region_center_position zone_center_position region_base zone_baseregion_height zone_height region_maximum_size zone_maximum_size

Additionally, for the embodiment, associated with the definition of eachregion/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304*-306* are additional geometricattributes further defining kernel 402/502 of the region/zone“container” cell 204*-206*. A kernel of a region/zone “container” cell204*-206* refers to the smallest manifestation of the region/zone“container” cell 204*-206*. That is, when the available space within ahost “container” cell 202-205* falls below the space required by thekernel of a region/zone “container” cell 204*-206*, the “container” cell204*-206* is to be “reduced” to an icon cell. For the embodiment, thekernel related geometric attributes include attributes defining aregion/zone “container” cell's kernel's size, base and height.region-cell zone-cell region_kernel_area zone_kernel_arearegion_kernel_base zone_kernel_base region_kernel_heightzone_kernel_height

Further, for the embodiment, associated with the definition of eachregion/zone “container” cell 202 and 204*-206*, and stored insidecorresponding data objects 302 and 304* 306* are geometric attributesfurther defining a boundary 406/506 of the region/zone “container” cell204*-206*. The boundary may also have related attributes includinggeometric/visual attributes defining a thickness and a color of theboundary of the region/zone “container” cell 204*-206*. region-cellzone-cell region_boundary_thickness zone_boundary_thicknessregion_boundary_color zone_boundary_color

In one embodiment, if the “boundary” attributes are not specified for aregion/zone “container” cell, the region/zone “container” cellautomatically inherits the “boundary” attributes of the nearest“ancestor” region “container” cells, where such attributes arespecified. In other words, an inheriting region/zone “container” celltakes on the characteristics of the bequeathing “ancestor” region“container” cell.

Associated with the definition of each region/zone “container” cell 202and 204*-206*, and stored inside corresponding data objects 302 and304*-306* may also include geometric attributes further defining aborder 404/504 of the region/zone “container” cell 204*-206*. The borderrelated attributes include geometric/visual attributes defining athickness, a color, a texture, a shading, a blinking and a transparencyattribute of the border of the region/zone “container” cell 204*-206*.region-cell zone-cell region_border_thickness zone_border_thicknessregion_border_color zone_border_color region_border_texturezone_border_texture region_border_shading zone_border_shadingregion_border_blinking zone_border_blinking region_border_transparentzone_border_transparent

In one embodiment, if the “border” attributes are not specified for aregion/zone “container” cell, the region/zone “container” cell alsoautomatically inherits the “border” attributes of the nearest “ancestor”region “container” cell, where such attributes are specified.

In various embodiments, for a region “container” cell 204*-205*, theattributes may further include policy attributes defining how many zone“container” cells it may have, their names and their default alignments(e.g. center, top, bottom, right, left and so forth), whereas for a zone“container” cell 206*, the attributes may further include a relationshipattribute defining its “host” region “container” cell 202 and 204*/205*.For a zone “container” cell 206*, the attributes may further includecontent attributes defining its content types, video, data, image, text,and so forth, and an external buffer 508.

In various embodiments, the policy attributes may also associate aninternal buffer(s) 409, 509 with variable algorithms that may beinitiated to change a cell's attributes, priorities, policies orbehaviors when the cell itself decreases in size and the cell bordertouches or encounters the internal buffer edge. The policy attributesmay also associate internal buffer(s) 409, 509 with variable algorithmsthat may be initiated to change other cells attributes, priorities,policies, or behaviors at any level of the hierarchy when the cellitself decreases in size and the cell border touches or encounters theinternal buffer edge. Further, the policy attributes may also associatean internal buffer(s) 409, 509 with variable algorithms that may beinitiated to change any section of the hierarchy, the entire hierarchy,the policies and behaviors of a section of or the entire hierarchy, orelements, applications, data external to the hierarchy or system itself,when the cell itself decreases in size and the cell border touches orencounters the internal buffer edge.

In various embodiments, the overlapping of two structures (collectionsof nested cells), e.g. the overlapping of one or more cells of thestructures, may be referred to as a “violation” (if the policyattributes of the structural elements so define). The policy attributesmay associate an internal buffer with a variable algorithm that may beinitiated to cause the entire hierarchy to collapse and be reduced to asingle icon, in the event of a “violation”. In different embodiments,the “violation” of structural elements, such as an internal buffer of asingle cell “violating” an external-buffer or other structural elementof another cell, may cause a wide variety of responses or changes to thehierarchy of cells or external to the hierarchy including causing cellsto iconize, shrink, swap, freeze in size or position, grow, becomevisible, transparent, or invisible, or move to other locations, cells tochange relative priorities, pop-up cells to become visible, policy orstructural changes anywhere in the system or hierarchy, thecommunication of an alarm, multimedia channel(s) to open, an applicationor applications to start on a client or remote server, a local or remotescript to run that alters any aspect of the client, network, remotedevice(s), a mechanical switch to be thrown, or any other actionallowable by the system to a portion of or the complete hierarchy ofcells (in accordance with policy or policies governing the processing ofthe “violations”. External buffer 508, on the other hand, may act likeinternal buffers or may define the minimum inter-zone “container” cellspacing between immediately adjacent zone “container” cells 206*.Similarly, the policy attributes of external buffer 508 may be associatethe buffer with a variable algorithm that may be initiated to changesthe cell's attributes, priorities, behaviors based on the cells that arewithin the external buffer area or touch the external buffer edge. Thepolicy attributes may also associate external buffer 508 with a variablealgorithm that may define an “area of influence” that alters theattributes, priorities, behaviors of other cells at any level of thehierarchy within the external buffer area or touch the external bufferedge based on algorithms or policies. region-cell zone-cellregion_zone_list = [zone-cell zone_region_association names]region_zone_alignment = [center, zone_video, zone_data, top, bottom,right, left] zone_image, zone_text region_max_allowable_zones = [number]

The above described attributes for region/zone “container” cells aremerely illustrative. In alternate embodiments, the present invention maybe practiced with more or less region/zone “container” cell attributes.For example, the present invention may be practiced with additionalattributes defining

a) the control facilities associated with the region/zone “container”attributes,

b) the behavior when certain areas of a region/zone “container” cell is“mouse over”, and

c) forced bequeathing of certain attributes to the more inner or lowerlevel region/zone “container” cells.

Further, the attributes of a nested container cell may be inherited fromany of its more outer container cells.

FIG. 6 illustrates the composition of an “action” cell, morespecifically, an image icon “action” cell in further detail, inaccordance with one embodiment. As described earlier, an image icon“action” cell is an iconic representation of another displayable orlaunch-able cell with content, control facilities and so forth. Further,“action” cells may also include cells defining control facilities, andcells defining “button” icon, which provide control facilities for aregion/zone “container” cell and action to be performed within aregion/zone “container” cell respectively. The description to follow foran image icon “action” cell may be likewise adopted to implement buttonicon “action” cells and/or control facilities cells.

As illustrated, for the embodiment, associated with the definition ofeach image icon “action” cell 208*-210* and stored inside acorresponding data object 314*-316* are geometric, visual andrelationship attributes defining e.g. the bit map of the image icon“action” cell, and the center position of the image icon “action” cell,a region/zone “container” cell with which the image icon “action” cellis associated, and a buffer 602. Buffer 602 defines the minimum spacerequired to display the image icon “action” cell. Icon-cellimage_icon_association = [region/zone-cell name]image_icon_center_position = [x, y] image_icon_actual = [bit_map_name]image_icon_buffer_base = [ ] image_icon_buffer_height = [ ]image_icon_upper_left_vertex_position = [x, y]

Similarly, in alternate embodiments, the present invention may bepracticed with more or less attributes (structural, geometric, visual,policy, behavior, and so forth) defining the various “action” cells, aswell as the contents to be rendered (i.e. video, graphics, texts, and soforth). The attributes may also be inherited from the immediate as wellas higher hierarchical level host container cells.

In particular, for button icon “action” cells and control facility“action” cells, each of the respective “action” cells may include one ormore behavior attributes in identifying the binaries to be executedresponsive to various types of user actions, e.g. “mouse over”, “singleclick”, “double clicks”, and so forth.

The binaries may specify one or more actions to be performed. The exactactions to be performed are application dependent. However, the one ormore actions may e.g., cause one or more contents to be rendered, one ormore contents to be processed, one or more container cells toinstantiated and be added among the currently active and visiblecontainer cells, one or more scripts to be executed, one or moredefining attributes to be added to, modified, or deleted from thedefining attributes of one or more cells, one or more cells to be addedto or deleted from the cell hierarchy of the EUI, one or more userinputs to be requested, or one or more system actions be taken.

Additionally, the one or more actions may be performed in associationwith or on behalf of one or more container cells. The one or morecontainer cells may be any container cells in any level of the cellhierarchy of the EUI. In other words, in embodiments of the presentinvention, the one or more actions to be performed need not be confinedto the immediate host container cell of the action cell (icon).

Further, the one or more actions to be performed may also be conditionedon one or more policy attributes of a host container cell, and/or one ormore state values of a container cell, which may or may not be the samecontainer cell on which's policy attributes the action(s) to beperformed is(are) conditioned. That is, the binaries may be designed ina manner that the various possible actions are conditionally performedbased on one or more attribute and/or state values of the one or morecontainer cells, with or on behalf of which, the actions are to beperformed.

In other words, under embodiments of the invention, an action cell(icon) may be employed e.g., to represent one or more regions,sub-regions and/or zones, and have the one or more regions, sub-regions,and/or zones to be instantiated and added among the currently visibleregions, sub-regions and/or zones. An action cell (icon) may be employedto cause contents to be processed in association with or on behalf ofthese regions, sub-regions or zones, or rendered in the regions,sub-regions or zones. An action cell (icon) may be employed to causeinputs to be requested of a user, or actions requested of a system, inassociation with or on behalf of these regions, sub-regions or zones.

An action cell (icon) may also be employed to cause regions,sub-regions, zone or icons be added or deleted from the EUI. An actioncell (icon) may also be employed to modify a region, sub-region, or azone, including adding, modifying or deleting defining attributes of theregions/sub-regions/zones. More importantly, these actions may be takenin association with, or on behalf of any regions, sub-regions or zonesdisposed at any level of the cell hierarchy of the EUI.

Referring briefly to FIG. 3 again, as described earlier, for theillustrated embodiment, region/zone “container” cells, “action” cells,and data (include video, graphics, text and so forth) are implemented inan object oriented manner, with corresponding data objects 302 and304*-316*. In one embodiment, as illustrated in FIG. 7, various methods700 are associated with the data objects 302 and 304*-316*. For theembodiment, these methods include in particular a clear, a contract, anexpand, a remove, and a set attribute method, 702-710, associated withthe root data object 302, and inherited by the descendant data objects304*-316* of the nested region/zone “container” cells 204*-206*, as wellas the descendant data objects 314*-318* of the nested “action” cells208*-210*.

Clear method 702, when invoked against universal region “container”cell's data object 302 clears the EUI 102, i.e. removing all nestedregion/zone “container” cells 204*-206*, including their contents, aswell as any nested “action” cells 208*-210*. In one embodiment, theuniversal region “container” cell clearing is efficiently achieved byclearing or deleting all descendant data objects 304*-316*. Innerinvocation against a region/zone “container” cell 204*-206* clears thenested regions/zones “container” cells 204*/206* within the targetregion/zone “container” cell 204* including their contents, and anynested “action” cells 208*-210*. In like manner, the clearing isefficiently achieved by clearing or deleting the applicable descendantdata objects 304*-316*.

Expand and contract methods 704-706 are employed to expand and contracta region/zone “container” cell 204*-206* respectively. Remove method 708facilitates removal of individual cells of the EUI 102, i.e. one or moreregions/zone “container” cells 204*-206* or “action” cells 208*-210*without clearing all cells. Removal is achieved in like manner as clearmethod 702, except the operation is applied to selected ones of thedescendant data objects, as opposed to all descendant data objects. SetAttribute method 710 facilitates setting of the earlier describedregion/zone “container” cell and “action” cell attributes associatedwith region/zone “container” cells 202 and 204*-206*, and “action” cellsrespectively.

For region/zone cells 204*-206* and “action” cells 208*-210*, theircorresponding data objects 304*-306* and 314*-316* further include theassociation of a create, and a delete, a move and a place method712-718. Create and delete methods 712-714, as their names suggest,facilitate creation and delete of the various descendant data objects304*-306* and 314*-316* for the nested region/zone “container” cells and“action” cells 204*-206* and 208*-210*. Move and place methods 716-718,as their names suggest, facilitate movement and relocation of thevarious region/zone “container” cells and “action” cells 204*-206* bymodifying e.g. the position attributes of the corresponding data objects304*-306* and 314*-316*.

For the embodiment, data objects 314*-316* for “action” cells 208*-210*further include the association of a launch method 720 for launching adisplayable region/zone cell 204*-206* represented by image icon“action” cells 210*.

With the exception of the handling of the impact that flows from thecreation, deletion, expansion and contraction of a region/zone“container” cell 204*-206*, implementation of the above describedmethods are within the ability of those ordinarily skilled in the art,accordingly will not be further described. Handling of the impact thatflows from the creation, deletion, expansion and contraction of aregion/zone “container” cell 204*-206* will be described in more detailbelow, referencing FIGS. 11-16.

FIGS. 8-9 illustrate two novel interactions with EUI 102, otherwise notavailable under the prior art, and the relevant operation flow of animplementor, such as an application, a cell manager or a window manager,incorporated with the teachings of the present invention. Asillustrated, by virtue of the earlier described novel architecture anddata organization, contents presented through two different zone“container” cells 206* may be easily interchanged or swapped, as denotedby arrow 802. The swapping operation may be initiated through any one ofa number of user key sequences, e.g. user key sequences similar to aconventional drag and drop operation. The swapping may be efficientlyaccomplished by switching association of the applicable data objects308*-316* and their region/zone “container” cells 204*-206*. Further,“action” cells 314*-316* may be easily relocated to any region/zone“container” cell 204*-206* as denoted by arrow 804.

As illustrated in FIG. 9, in response to a non-region/zone “container”cell impacted user interaction, an implementor (such as an application,a cell manager or a window manager incorporated with the teachings ofthe present invention) determines if the sequence of user inputs denotesa drag and drop of content from one region/zone “container” cell204*-206* to another, block 902. If so, the implementor effectuates thecontent swapping, by switching the data objects' association with theirregion/zone “container” cells 204*-206*, as earlier described, block904.

If the sequence of user inputs does not denote a drag and drop ofcontent, for the embodiment, the implementor further determines if thesequence of user inputs denotes an “action” cell drag and drop, block906. If so, the implementor effectuates the “action” cell movement andplacement by similarly switching the “action” cell's association withregion/zone “container” cells 204*-206*, optionally launching therepresented region/zone “container” cell 204*-206* and its contents (ifso requested by the sequence of user inputs), block 908.

If the sequence of user inputs does not denote either one of these novelinteractions supported, the denoted prior art request may then beprocessed as in the prior art.

The sequence of user inputs denoting the earlier described content and“action” cell drag and drop may be practiced through any key sequences,e.g. by clicking on the content or icon, using a cursor control device,and keeping the applicable click button of the cursor control deviceheld down, until the target region/zone “container” cell 206* isreached. At such time, the click button of the cursor control device maybe returned to its normal position. In alternate embodiments, thepresent invention may be practiced with other key sequences instead.

FIG. 10 illustrates an overview of the operation of EUI 102. The currentstate of EUI 102 as defined by the current states of the correspondingdata objects 302-316* of the constituting cells 202-210* of EUI 102, asillustrated, is referred to as the current view of EUI 102. In responseto user interactions, such as a request to add or remove a region/zone“container” cell 204*-206*, or a request to expand or contract aregion/zone “container” cell 204*-206*, the implementor of the presentinvention, e.g. an application, a cell manager or a window manager,performs a series of responsive calculations, and generate the next viewof EUI 102.

The operational flow of the relevant aspects of the implementor, inresponse to the various user interactions of interest, will be describedin turn below.

FIG. 11 illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell manager or a window manager,for responding to a request to add a region/zone “container” cell or an“action” cell to a region/zone “container” cell, or expand a region/zone“container” cell (hereinafter, for the description of FIG. 11, simplythe “add/expand” request), in accordance with one embodiment. Asillustrated, for the embodiment, the implementor first determines if therequested addition or expansion fits in the current available space ofthe host region/zone “container” cell, block 1102. The required space toaccommodate the requested addition/expansion may e.g. be determined fromthe attribute values of the “new” or expanded region/zone “container”cell. If the requested addition or expansion fits in the currentavailable space of the host region “container” cell, the requestedaddition or expansion is performed accordingly, block 1104.

However, if the requested addition or expansion does not fit in thecurrent available space of the host region/zone “container” cell, theimplementor successively undertakes one or more space creation actions,until either sufficient amount of available space has been created oruntil all possible space creation actions have been exhausted, blocks1102-1108. As soon as sufficient available space has been created,operation continues at block 1104 as earlier described.

However, if all possible space creation actions have been exhausted andthe amount of space required to accommodate the requested addition orexpansion remains insufficient, the implementor successively undertakesone or more space requirement reduction actions, until either therequired space has been reduced below the amount of available space oruntil all possible space reduction actions have been exhausted, blocks1110-1112. Similarly, as soon as the required space to satisfy theaddition or expansion request is reduced below the available space,operation continues at block 1104 as earlier described.

If likewise, all possible required space reduction actions areexhausted, and the amount of space required to accommodate theadd/expand request remains above the available space, an “error”, suchas “unable to add/expand”, is returned in response to the request.

In one embodiment, available space creation actions include shiftingexisting region/zone “container” cells within the host region/zone“container” cell the add/expand request is to be performed, and reducingthe existing region/zone “container” cells if necessary. In oneembodiment, shifting of existing region/zone “container” cells includesshifting the existing regions/zone “container” cells to a predeterminedcorner of the host region/zone “container” cell, e.g. the lower leftcorner, the upper left corner, the upper right corner or the lower rightcorner. In one embodiment, shifting of existing region/zone “container”cell to a corner is performed by aligning the region/zone “container”cells along one or the other boundary forming the corner. In anotherembodiment, shifting of existing region/zone “container” cells to acorner is performed by alternating in aligning the regions/zone“container” cells along the boundaries forming the corner.

In one embodiment, reducing the existing region/zone “container” cellsis performed in an incremental manner. In another embodiment, reducingthe existing region/zone “container” cells is performed in accordancewith the relative priorities of the existing region/zone “container”cells. In one embodiment, reduction is performed in an incrementalmanner as well as in view of the relative priorities of the existingregion/zone “container” cells. In one embodiment, the lowest priorityregion/zone “container” cell is first successively reduced to its kernelbefore the next higher priority region/zone “container” cell issuccessively reduced towards its kernel. In another embodiment, thereduction is successively performed in a round robin manner. In yetanother embodiment, reduction of existing region or zone “container”cells further includes reducing one or more of the existing region/zone“container” cells to their icon “action” cell representations. Again, inone embodiment, the reduction to iconic representation is performed inview of the relative priorities of the existing region/zone “container”cells.

In one embodiment, reduction of required space action includessuccessively reducing the size of the region/zone “container” cell to beadded, or to be expanded to.

Still referring to FIG. 11, back at block 1104, upon performing therequested addition/expansion, the implementor determines if any postaddition/expansion operations need to be performed. If so, the postaddition/expansion operations are performed, block 1118. If not, theprocess terminates.

Post addition/expansion operations may be required, as existingregion/zone “container” cells may have been shifted to one corner of thehost region/zone “container” cell or reduced, even to their kernel, inthe course of accommodating the addition/expansion request. Accordingly,for the embodiment, upon accommodating the addition/expansion, attemptsare made to at least partially restore the shifted and/or reducedregion/zone “container” cells back to the pre-request state. Similarly,the post addition/expansion operations may include successivelyexpanding reduced existing region/zone “container” cells, which may alsobe performed in view of the relative priorities, re-shifting shiftedregion/zone “container” cells (e.g. out from the coalesce corner) toachieve a more balance alignment of the nested region/zone “container”cells within the host region “container” cell. “Balance” may be measurede.g. by the average space gap between the boundaries of the variousregion/zone “container” cells.

FIG. 13 illustrates an exemplary addition of a new region/zone“container” cell into a region “container” cell having two existingregion/zone “container” cells, in accordance with the above describedprocess. As illustrated, the two existing region/zone “container” cellsare first shifted to the lower left corner, with the two existingregion/zone “container” cells aligned along the left boundary formingthe lower left corner (illustrations A & B). Since there isn't enoughavailable space to add the requested new region/zone “container” cell,the two existing region/zone “container” cells are successively reduced,eventually to their kernels, first the lower priority region/zone“container” cell, then the higher priority region/zone “container” cell(illustrations C-D). The new region/zone “container” cell is then addedto the newly created space in the opposite upper right corner(Illustration E). Further, the reduced region/zone “container” cells areshifted back out from the lower right corner and aligned in the bottomportion of the host region/zone “container” cell (illustration F & G).

FIG. 14 illustrates another exemplary addition of a new region/zone“container” cell into a region/zone “container” cell having threeexisting region/zone “container” cells, in accordance with the abovedescribed process. Except in this illustration, the existing region/zone“container” cells are first shifted to the upper left corner, and thenshifted out along the top portion of the host region/zone “container”cell instead. Further, the new region/zone “container” cell is reducedto reduce its space requirement before it is added to the hostregion/zone “container” cell.

FIG. 12 illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell-cell manager or a windowmanager, for responding to a request to remove a region/zone “container”cell from a region “container” cell, or an “action” cell from aregion/zone “container” cell (hereinafter, for the description of FIG.12, simply the “remove/contract” request), in accordance with oneembodiment. As illustrated, for the embodiment, the implementor removesor contracts the region/zone “container” cell, or the “action” cell asrequested, block 1202. Thereafter, the implementor determines if thethere are iconized region/zone “container” cells of the host region/zone“container” cell that can be restored into the newly increased availablespace of the host region/zone “container” cell, block 1204. If so, theimplementor restores one or more of the eligible iconized region/zone“container” cells, subject to the available space, block 1206. In oneembodiment, the restoration is performed in accordance with the relativepriorities of the iconized region/zone “container” cells.

Upon exhausting the possibility of restoring iconized region/zone“container” cells (either because there are none left or there isn'tenough space), the implementor determines if there are any reducedregion/zone “container” cells that can be grown towards their maximumsizes, block 1208. If so, the implementor successively grows one or moreof the reduced region/zone “container” cells, subject to the availablespace, block 1210. In one embodiment, the successive growth is alsoperformed in accordance with the relative priorities of the reducedregion/zone “container” cells.

Next, similar to the process of adding or expanding a region/zone“container” cell, upon restoring or growing the iconized or reducedregion/zone “container” cells, the implementor determines if any postrestoration or growth actions need to be performed, block 1212. If so,the implementor performs the post restoration or growth actions, such asshifting and aligning to “re-balance” the region/zone “container” cellsof the host region/zone “container” cell, block 1214. As before,“balance” may be measured e.g. by the average space gap between theboundaries of the various region/zone “container” cells FIG. 15illustrates the operational flow of the relevant aspects of animplementor, e.g. an application, a cell manager or a window manager forresponding to a request to expand a region “container” cell(hereinafter, for the description of FIG. 15, simply the “add/expand”request), in accordance with another embodiment. In this embodiment, forefficiency of operation, region “container” cells are nested within ahost region “container” cell in a contiguous manner, i.e. withoutavailable space gap between their boundaries.

As illustrated, in response to a request to grow a region “container”cell by an amount, the implementor first generates extended boundariesfor the growth region “container” cell (see FIG. 16), block 1502. Next,the implementor determines growth impact for up to n levels removed inall directions, using the extended boundaries.

For example, for the exemplary growth request illustrated in FIG. 16,growth impact of the center region “container” cell may be determinedusing its extended boundaries, based on their intersections with otherboundaries. The impacts on region “container” cells up to 2 degreesremoved from the center region “container” cell may be summarized asfollows: up down left right Neighbor region A, B F, E H, G C, D“container” cell affected Second level none none special L, K, J region“container” case cell affected Side Effects H, C D F none

Thereafter, for the embodiment, the implementor iteratively expands theregion “container” cell in the various directions, adjusting theimpacted region “container” cell to accommodate the growth, block 1506.The process continues until the desired amount of growth is achieved. Ifthe desired growth is not achievable, for the embodiment, an “error”,such as “growth unachievable”, is returned, block 1508.

As alluded to earlier, the present invention may be practiced e.g. byendowing an application itself, a cell manager or a window manager withthe teachings of the present invention. In the latter cases, acell/window manager implementor may be effectuated in at least twomanners, FIG. 17 a and FIG. 17 b. In the embodiment of FIG. 17 a, cellmanager 1704 is equipped with teachings of the present inventioninterfaces and interacts with applications 1702 using its services, anddisplay device driver 1706 as in the prior art. Accordingly, under thisembodiment, typically, the universal region “container” cell 202 is theentire display space of a display device.

In the alternate embodiment of FIG. 17 b, the cell manager implementoroperates as an “auxiliary” cell manager 1703 to a conventional windowmanager 1704. Applications 1702 may interact with conventional windowmanager 1704 directly or indirectly through auxiliary cell manager 1703(equipped with the teachings of the present invention). Accordingly,universal region “container” cell 202 may be a window of a conventionalwindow approach, except within that window, the EUI is implemented andpracticed as earlier described, in accordance with the presentinvention.

In yet other alternate embodiments, auxiliary cell manager 1703 may beintegrally incorporated as part of window manager 1704.

FIG. 18 illustrates an exemplary computer system or device suitable forpracticing the present invention, in accordance with one embodiment. Asshown, computer system/device 1800 (hereinafter simply “device”)includes one or more processors 1802 and system memory 1804.Additionally, device 1800 includes mass storage devices 1806 (such asdiskette, hard drive, CDROM and so forth), input/output devices 1808(such as keyboard, cursor control and so forth) and communicationinterfaces 1810 (such as network interface cards, modems and so forth).The elements are coupled to each other via system bus 1812, whichrepresents one or more buses. In the case of multiple buses, they arebridged by one or more bus bridges (not shown). Each of these elementsperforms its conventional functions known in the art. In particular,system memory 1804 and mass storage 1806 are employed to store a workingcopy and a permanent copy of the programming instructions implementingthe implementor of the present invention, e.g. an application, a cellmanager or a window manager. The permanent copy of the programminginstructions may be loaded into mass storage 1806 in the factory, or inthe field, through a distribution medium (not shown) or throughcommunication interface 1810 (from a distribution server (not shown)).The constitution of these elements 1802-1812 are known, and accordinglywill not be further described.

FIG. 19 shows an exemplary network environment suitable for practicingthe present invention, in accordance with one embodiment. In thisembodiment, contents are presented for user of client device 1902 toenjoy, employing the hierarchical cell based EUI 102 of the presentinvention. In one embodiment, display device 1904 a on which EUI 102 isrendered, is an integral of client device 1902. In another embodiment,display device 1904 b on which EUI 102 is rendered, is an separate anddistinct “peripheral” of client device 1902.

In various embodiments, the implementor of the present invention, e.g.an application, a cell manager or a window manager, may be executing onclient device 1902 itself. In other embodiments, the implementor may beexecuting on server 1906 instead. Examples of the former case may be apersonal computer, an enhanced integrated television set, and a set-topbox. Examples of the latter case may be a content streaming server or acable programming broadcasting device.

Client device 1902 and server 1906 are coupled to each other via one ormore private and/or public networks, including e.g. the Internet,employing Digital Subscriber Lines (DSL) (or other variants xDSL), CableNetwork, Integrated Digital Service Network (ISDN), AsynchronousTransfer Mode (ATM), Frame Relay, or other high performancecommunication links/connections of like kind. Communications betweenclient device 1902 and server 1906 may be accomplished via any one of anumber of communication protocols known in the art, including but arenot limited to the TCP/IP protocol.

Examples of content may include one or more of the following content orprogram types Special Events News TV Sports Concerts Live Reality GolfOlympics Produced Network Football Political Shows Syndication RacingRallies Children's TV Football Amusement Treasure Hunts Soccer Plays

Thus, a novel EUI method and apparatus has been described. Althoughspecific embodiments have been illustrated and described herein, it willbe appreciated by those of ordinary skill in the art that a wide varietyof alternate and/or equivalent implementations may be substituted forthe specific embodiments shown and described, without departing from thescope of the present invention. This application is intended to coverany adaptations or variations of the embodiments discussed herein.Therefore, it is manifestly intended that this invention be limited onlyby the claims and the equivalents thereof.

1. An end user interface (EUI) comprising: a first display containercell; a second display container cell nested within the first displaycontainer cell; and a first action cell nested within one of said firstand second display container cells, the first action cell beingassociated with causing at least a first action to be performed inassociation with or on behalf of at least one of a third displaycontainer cell and a fourth display container cell.
 2. The EUI of claim1, wherein the first display container cell is a selected one of a rootregion container cell and a nested region container cell.
 3. The EUI ofclaim 1, wherein the second display container cell is a displaycontainer cell selected from a display container cell group consistingof a nested region container cell, a nested zone container cell, and anested action cell pool container cell.
 4. The EUI of claim 1, whereinthe fourth display container cell is nested in the third displaycontainer cell.
 5. (canceled)
 6. (canceled)
 7. (canceled)
 8. (canceled)9. (canceled)
 10. The EUI of claim 1, wherein the fourth displaycontainer cell is an invisible cell.
 11. The EUI of claim 1, wherein thefirst action cell is associated with causing a first action to beperformed in association with or on behalf of both the third containercell and the fourth container cell.
 12. The EUI of claim 11, wherein thefirst action cell is further associated with causing a second action tobe performed in association with or on behalf of at least one of thethird and the fourth container cell.
 13. The EUI of claim 1, wherein thefirst action cell is further associated with causing a second action tobe performed in association with or on behalf of at least one of thethird and the fourth container cell.
 14. The EUI of claim 1, wherein thefirst action comprises performing an action selected from an actiongroup consisting of adding a display container cell as a currentlyvisible display contain cell among one or more other currently visibledisplay container cell, rendering a content, process a content andcausing a script to be executed.
 15. The EUI of claim 1, wherein thefirst action comprises performing an action selected from an actiongroup consisting of requesting a user action, requesting a local systemaction, and/or requesting a remote system action.
 16. The EUI of claim1, wherein the first action cell has a plurality of associatedattributes defining the first action cell, including attributes selectedfrom a attribute group consisting of one or more structural attributes,one or more geometric attributes, one or more visual attributes, one ormore policy attributes, and one or more behavior attributes.
 17. The EUIof claim 1, wherein the first action comprises performing an actionselected from an action group consisting of associating a definingattribute with a display container cell, modifying a defining attributeassociated with a display container cell, and deleting a definingattribute associated with a display container cell.
 18. The EUI of claim1, wherein the first action comprises performing an action selected froman action group consisting of adding one or more cells to the EUI, anddeleting one or more cells from the EUI.
 19. The EUI of claim 1, whereinthe first action associated with the first action cell is associatedbased at least in part on one or more attributes of one or more of thedisplay container cells within which the first action cell is nested.20. The EUI of claim 1, wherein the first action associated with thefirst action cell is associated based at least in part on one or morecurrent state values of one or more of the display container cellswithin which the first action cell is nested.
 21. The EUI of claim 1,wherein the first action associated with the first action cell is anaction to be performed in response to a structural exception eventinvolving the at least one of the fourth and fifth display containercells.
 22. The EUI of claim 1, wherein the EUI further comprises asecond action cell associated with causing at least a second action tobe performed in association with or on behalf of one or more nestedcontainer cells.
 23. A computing device implemented method comprisingrendering a first display container cell of an end user interface (EUI);rendering a second display container cell of the EUI nested within thefirst display container cell; and rendering an action cell of the EUInested within one of said first and second display container cells, theaction cell being associated with causing at least a first action to beperformed in association with or on behalf of at least one of a thirdcontainer cell and a fourth container cell.
 24. The method of claim 23,wherein said rendering of the action cell is performed in view of aplurality of associated attributes of the action cell defining actioncell, the associated attributes being attributes selected from aattribute group consisting of one or more structural attributes, one ormore geometric attributes, one or more visual attributes, one or morepolicy attributes, and one or more behavior attributes.
 25. The methodof claim 23, wherein the method further comprises performing the actionin response to a user selection of the first action cell, and the actionbeing an action selected from an action group consisting of adding adisplay container cell as a currently visible display contain cell amongone or more other currently visible display container cell, rendering acontent, process a content and causing a script to be executed.
 26. Themethod of claim 23, wherein the method further comprises performing theaction in response to a user selection of the action cell, and theaction being an action selected from an action group consisting ofassociating one or more defining attributes with a display containercell, modifying one or more defining attributes associated with adisplay container cell, deleting one or more defining attributesassociated with a display container cell, adding one or more cells tothe EUI, and deleting one or more cells from the EUI.
 27. The method ofclaims 23, wherein the method further comprises performing the action inresponse to a user selection of the action cell, and the actionassociated with the action cell is associated based at least in part onone or more attributes or one or more state values of one or more of thedisplay container cells within which the action cell is nested.
 28. Asystem comprising: a processor; a display coupled to the processor; andstorage coupled to the processor, and having stored therein instructionsdesigned implement an end user interface for the system, the end userinterface having a first display container cell; a second displaycontainer cell nested within the first display container cell; and afirst action cell nested within one of said first and second displaycontainer cells, the first action cell being associated with causing atleast a first action to be performed in association with or on behalf ofat least one of a third container cell and a fourth container cell. 29.The system of claim 28, wherein the first action comprises an actionselected from an action group consisting of adding a display containercell as a currently visible display contain cell among one or more othercurrently visible display container cell, rendering a content, process acontent and causing a script to be executed.
 30. The system of claim 28,wherein the first action comprises an action selected from an actiongroup consisting of associating one or more defining attributes with adisplay container cell, modifying one or more defining attributesassociated with a display container cell, deleting one or more definingattributes associated with a display container cell, adding one or morecells to the EUI, and deleting one or more cells from the EUI.
 31. Thesystem of claim 28, wherein the first action associated with the firstaction cell is associated based at least in part on one or moreattributes or one or more state values of one or more of the displaycontainer cells within which the first action cell is nested.
 32. Thesystem of claims 28, wherein the EUI further comprises a second actioncell associated with causing at least a second action to be performed inassociation with or on behalf of one or more nested container cells.